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ABSTBACT 


In  previous  reports,  CDLl,  —  a  computer  description  language  —  has 
been  defined  and  discussed.  TMa  report  discusses  the  Implementation  of  a 
system  of  programs,  on  the  RCA  Spectra  70  computers,  to  generate  appropriate 
file  structures  from  computer  descriptions  written  In  CDLl.  This  trans¬ 
lation  to  a  DDB  —  descriptive  data  base  —  Involves  syntactic  analysis 
and  a  certain  amount  of  checking  for  Internal  consistency,  as  well  as  the 
creation  of  directory  entries,  etc.  Once  the  type  of  DDB's  described 
in  this  report  can  be  generated,  a  variety  of  design-aid  systems  can  be 
based  upon  them,  saving  a  duplication  of  effort,  guaranteeing  an  Integrated 
overall  system,  and  avoiding  built-in  obsolescence. 

The  final  state  of  the  work  done  under  this  contract  Is  given,  with 
details  of  the  file  and  directory  structures  which  have  been  Implemented. 
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FOREWORD 


TKls  Scientific  Report  No.  4  wee  prepared  at  RCA  Laboratories,  Princeton, 
New  Jersey,  under  Contract  No.  F19628-68-C-0070.  The  report  was  written  by 
Dr.  C.  V.  Srinlvasan  who  is  now  on  the  Faculty  of  Rutgers,  the  State  University, 
at  its  Livingston,  N.J.,  caapus.  The  report  coaipletes  the  work  done  at  RCA 
on  CDLl. 
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1.  INTRfflXJCTIOM 


I  would  like  to  outline  In  this  report  the  Inpleasntatlon  task  ahead 
of  us  In  the  developsMnt  of  a  Descriptive  Data  Baw  (DDB)  for  computing 
system  descriptions,  based  on  the  language  CDL1«  [1>2].  Let  me  first  explain 
what  DDB  Is,  what  purpose  It  Is  to  serve  in  a  computer  system  design  environ- 
ment,  and  to  begin  with,  how  It  may  be  used. 

1.1  DDB.  What  It  Is  and  How  It  Is  to  Be  Used 

The  Cmputer  Description  Language,  CDLl,  provides  basically  the  follow¬ 
ing  two  facilities: 

(A)  It  provides  a  systematic  way  of  describing  situations  that  arise 

In  a  computer  system  design  activity,  at  the  level  of  System  Architecture  and 
Logic  Design.  This  Involves  facilities  to  describe  system  and  logical  structures 
and  tasks  performed  by  them.  The  tasks  themselves  could  be  described  either 
functionally  (Independent  of  their  Implementation),  or  In  terms  of  data-flow 
sequences  Initiated  by  them  within  an  abstract  system  (this  would  be  specific 
to  a  given  system  architecture),  or  In  terms  of  control/ command  sequences 
appearing  within  a  system  (specific  to  a  given  control  structure) .  These 
different  descriptions  of  a  task  would  reflect  In  a  natural  way  the  different 
stages  of  design  of  a  system,  stages  of  partial  definition  of  the  logical 
structure  of  the  system.  As  design  progresses  the  total  system  description 
would  get  built  up  In  terms  of  descriptions  of  the  various  sub-systems  and  their 
Interfaces.  In  fact,  the  design  process  itself  would  be  viewed  as  one  of 
generating  the  successive  levels  of  descriptions.  In  Increasing  levels  of 
logical  detail.  In  a  design  environment,  this  generative  process  would  be  a 
collective  activity  Involving  the  participation  of  several  designers. 

(B)  The  language  also  provides  a  scheme  for  filing  the  descriptions  so 
produced.  Each  body  of  description  would  contain  Implicit  Information  on  how 

It  should  be  filed,  and  how  It  should  be  embedded  within  the  body  of  description 
already  In  file.  Thus,  the  way  the  descriptive  file  might  grow  would  depend  on 
the  descriptions  themselves. 

The  features  of  the  language  which  provide  for  these  facilities  were 
discussed  In  earlier  reports  [1}.  An  overall  Introduction  to  the  language 
appears  In  AFCRL-67-0565  [2]  and  the  formal  definition  of  CDLl  In 
AFCRL-67-0588  [3]. 

The  essential  task  In  the  development  of  the  DDB  Is  one  of  producing 
the  software  for  CDLl  File  Establishment  (CDLFE).  The  CDLFE  process  involves 
the  following: 


’^CDLl  Is  a  Computer  Description  Language. 
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1)  Syntactic  analysis  of  Input  descriptions  in  CDLl  to  validate  them. 

11)  Limited  Interpretation  of  the  syntax  for  checking  consistency  of 

descriptions  and  their  completeness  (In  some  sense))  for  determining 
the  directory  entries  to  be  made  for  a  given  body  of  description, 
and  for  encoding  of  a  description  Into  Its  Internal  format. 

The  data  files  so  created,  together  with  their  directories  would  con¬ 
stitute  the  DDB  (Descriptive  Data  Base).  This  n)B  is.  In  fact,  simply  an 
elaborate  synJjol  table.  The  symbols  used  In  the  DDB  would  denote  very  complex 
objects.  Hence,  to  store  and  access  the  definitions  pertaining  to  the  symbols 
It  would  be  necessary  to  have  a  data  structure  more  complex  than  that  of  a 
simple  table.  The  details  of  this  data  structure  are  Inferred  from  the  de¬ 
scriptions  themselves.  Figure  1  shows  the  block  diagram  of  the  CDLFE  process. 
The  figure  Is  self-explanatory. 

The  DDB  would  establish  a  comnon  context  within  which  a  variety  of  auto¬ 
matic  design  aids  could  be  developed.  Each  such  design  aid  system  would 
communicate  with  the  DDB  via  a  Data  Retrieval  and  Abstracting  Facility.  The 
development  of  the  description  language  has  led  us  not  only  to  Identify  the 
kinds  of  system  design  aids  that  one  could  develop,  but  also  has  pointed  the 
way  to  some  novel  techniques  of  realizing  them. 

1.2  How  I  Propose  to  Ose  DDB  Now 

The  DDB  together  with  the  Data  Retrieval  (DR)  facility  would  constitute 
the  Design  Documentation  System  (DDS).  Figure  2  shows  a  block  diagram  of  the 
DR  facility.  This  figure  Is  self-explanatory  too.  The  DDS  as  presently 
conceived  would  not  only  establish  a  foundation  for  developing  a  variety  of 
design  aid  systems  of  the  future  but,  more  Importantly,  would  be  of  Immediate 
use  and  benefit  to  all  current  system  design  efforts,  purely  as  a  powerful 
(flexible),  mechanized,  central  documentation  facility  for  all  designs.  The 
value  of  having  such  a  central  documentation  facility  cannot  be  overemphasized. 

Once  the  DDB  Is  created,  work  on  the  development  of  DR  could  proceed 
simultaneously  with  several  other  design  automation  efforts.  For  example, 
one  could  easily  undertake  the  development  of  data-flow  simulators  (EO- 
slmulators)  In  the  context  of  the  DDB,  as  also  functional  simulators  at  a 
level  higher  than  the  data  flow.  The  availability  of  DDB  would  make  It  pos¬ 
sible  to  think  In  concrete  terms  about  the  various  design  aid  systems.  Also, 

It  would  provide  the  guarantee  that  the  systems  so  developed  could  all  be 
Integrated  into  a  central  design  aid  facility. 
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Figure  1.  Block  Dlaarin  of  CDLl  File  EBtabllshment  Process 


Figure  2,  Block  Diagram  of  the  Data  Retrieval  Facility 


The  development  effort  necessary  to  create  such  a  DDE  would  be  far  less  than 
what  would  be  necessary  If  one  chose,  for  example,  to  develop  a  data-flow 
slsulator  starting  from  scratch.  1  think  one  should  be  very  careful  about 
choosing  design  automation  projects  conceived  In  Isolation  outside  the 
context  of  a  general  design  eld  system,  for  such  projects  have  the  disadvantage 
of  built -In  obsolescence.  Beginning  the  design  automation  effort  with  the 
construction  of  DDE  appears  to  me  as  a  very  sensible  approach  from  the  view¬ 
point  of  technical  feasibility,  practical  needs,  and  future  promise. 

Let  me  now  explain  some  of  the  details  Involved  In  the  CDLFE  procedure. 
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2.  THE  CDLl  FI1£  ESTABLISBWEMT  fCDLFB)  PROCESS 
2.1  The  Present  State  of  Our  Work 


The  tasks  to  be  perfcir!ned  In  the  CDLFE  process  are  shovn  in  Figure  1. 

Those  appearing  above  the  dashed  line  AA'  In  Figure  1  are  directly  associated 
with  CDLl  and  depend  totally  on  CDLl  characteristics.  The  file  management 
task,  appearing  below  the  line  AA',  could  be  part  of  the  operating  system  In 
which  CDIFE  would  function.  1  shall,  therefore,  confine  my  discussion  here 
only  to  the  tasks  appearing  above  AA*. 

The  software  for  the  lexical  and  syntactic  analysis  of  CDLl  strings  Is 
now  aliiK>st  ready.  The  syntactic  analysis  Is  specified  only  for  a  subset  of 
CDLl.  (It  excludes  all  expressions  In  the  language  and  only  the  general  forms 
of  CDLl  statements  and  declarations  are  Included.)  The  detail  of  the  analysis 
would  be  Just  sufficient  for  the  purposes  (11),  (111)  and  (Iv)  Indicated  In 
Figure  1  within  the  'SYNTAX  INTERPRETATION'  block.  The  lexical  and  syntactic 
analyzers  have  been  individually  debugged,  and  have  had  a  single  successful 
run  together.  Further  debugging  should  be  done.  Also,  the  syntax  table  needs 
a  few  additions  and  modifications.  The  block  diagram  of  the  routines  Is  shown 
in  Figure  3.  The  syntax  table  for  the  CDLl  subset  was  produced  by  the  LRl 
processor  written  by  A.  J.  Korenjak  [4,53.  This  technique  of  syntax  table 
generation  has  Incidentally  established  CDLl  to  be  a  deterministic  language 
(parsable  without  backup).  All  software  packages  shown  In  Figure  3  were 
written  In  the  SPECTRA  assembly  language.  The  box  with  dashed  lines  In  the 
figure  Is  yet  to  be  described. 

The  lexical  analyzer,  together  with  the  hash  and  associated  tables  and 
hash  routines,  occupies  about  11  000  bytes.  This  area  includes  the  buffer 
blocks  for  future  directory  building.  The  syntax  tables  occupy  about  28  000 
bytes,  and  the  stack  manipulator  occupies  about  580  bytes. 

The  major  unfinished  task  ahead  of  us  Is  syntax  Interpretation.  It 
should  be  noticed  that  the  Interpretation  Is  not  for  producing  an  output  code 
In  an  object  language  as  Is  done  In  a  compiler,  but  It  Is  for  finding  out  how 
a  given  body  of  description  should  be  filed.  The  consistency  and  completeness 
checks  sould  be  Incidental  to  file  establishment.  For  the  present  we  have 
planned  to  Implement  only  the  completeness  checks  for  the  definitions  In  the 
langtiage.  To  check  consistency  It  would  be  necessary  to  have  a  greater .degree 
of  syntax  analysis  than  what  has  been  presently  implemented.  The  Information 
for  building  the  directory  Is  obtained  almost  entirely  from  the  declarations 
in  the  language.  The  part  of  the  directory  not  determined  by  the  declarations 
Is  dependent  upon  the  module  structure*  of  the  descriptions,  and  the  statements 
appeaz...ig  within  them.  The  design  specification  for  the  DDB  Is  now  complete. 
This  involves  mainly  the  design  of  the  directory  for  accessing  the  DDB. 


^Modules  are  basic  units  of  descriptions  In  the  language. 
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Block  Diagram  of  Lexical  and  Syntax  Analvters  for  the 


The  organization  of  the  software  packages  necessary  to  produce  the  ODB,  start¬ 
ing  from  the  parse  tree  of  descriptions  In  CDLl,  has  not  yet  been  decided 
upon.  The  entire  DDB  establishment  software  Is  going  to  be  written  In  terms 
of  macros.  A  suitable  collection  of  macros  for  the  purpose  Is  now  being 
defined  In  SMOBOL.  These  macros.  In  fact,  would  constitute  a  special-purpose 
Implementation  language  for  the  COLFE  processor.  The  software  written  In 
the  macros  would  be,  In  a  sense,  machine- Independent.  To  transfer  the  system 
software  to  another  machine  It  would  be  only  necessary  to  redefine  the  macros. 
We  believe  that  as  an  Implementation  tool  these  macros  would  be  very  useful 
In  a  variety  of  system  software  Implementation  tasks. 

Let  me  now  briefly  describe  the  DDB  directory  structure. 

2.2  DDB  Directory  Structure 

(A)  File  Structure 

The  DDB  file  Is  a  page-organized  file.  Each  page  Is  2048  bytes  long  and 
has  seven  attributes  associated  with  It.  These  attributes  are  shown  In 
Table  I.  The  attribute  value  of  a  page  is  Indicated  by  the  page  flag  which  Is 
eight  bits  long.  The  bits  of  the  page  flag  are  set  to  0  or  1  depending  upon 
the  values  of  Its  attributes.  In  the  order  shown  in  Table  I.  This  flag  Is 
part  of  the  page  header,  shown  in  Figure  4. 


TABLE  I 

PAGE  ATTRIBPTES 


Bit  No. 

In  the 

Page  Flag 

Attribute 

Name 

Attribute  Values 

0 

1 

0 

TYPE 

data 

directory 

1 

Version 

old 

new 

2 

Changes 

no 

yes 

3 

State 

clean 

dirty 

4 

Record  Length 

variable 

fixed 

5 

Size 

single 

double 

6 

Vacancy 

yes 

no 

The  various  fields  In  the  page  header  are  Intended  for  the  following  purposes: 

(1)  VP#.  This  Is  the  Virtual  Page  Nusdier  of  the  page.  VP#  Identifies 
a  page  uniquely.  This  header  entry  may  be  used  to  verify  a  page  Identity 
when  It  la  brought  Into  core. 

(11)  Page  Flag.  This  denotes  the  page  classification  according  to  Its 
attributes,  shown  in  Table  I.  The  attributes  have  the  following  significance: 

a)  Type:  Directory  pages  are  handled  differently  from  the  data  pages  for 
storage  and  updating. 
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Figure  4.  Page  Header  Format.  The  numbers  within  the  boxes  Indicate 
the  size  of  the  box  in  bytes  (8  bits/byte) 


b)  Version:  If  the  version  of  a  page  is  OLD  then  it  needs  updating. 

The  editing  comnands  for  updating  the  page  may  be  stored  separately  in  a 
different  page.  The  pointer  to  the  editing  commands  would  appear  In  the 
last  2-byte  field  of  the  header.  Just  before  the  group  definition  field  (see 
Figure  4).  If  the  editing  cooDands  are  used  on  the  page  then  the  version 
of  the  page  would  change  to  NEW. 

c)  Changes;  This  indicates  whether  a  page  in  core  had  been  written 
into  or  not.  If  the  value  of  this  attribute  is  YES,  then  the  page  should  be 
stored  back  on  the  disc  before  it  is  dropped  from  the  core;  otherwise,  it 
may  be  dropped  without  disc  transfer. 

d)  State;  A  dirty  page  requires  garbage  collection  and  a  clean 
page  does  not. 

e)  Record  Length:  The  significance  is  obvious. 

f)  Size:  In  certain  cases,  two  pages  may  be  treated  together  as 
though  they  were  one  large  page.  This  attribute  Indicates  the  appropriate 
size  of  the  page, 

«  g)  Vacancy:  The  significance  is  obvious. 

(ill)  Length  Field:  For  pages  with  fixed-length  records  the  record 
"  length  is  stored  in  this  field.  The  maximum  permissible  fixed-length 

record  length  is  256  bytes. 
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(Iv)  Record  Count:  The  nunber  of  records  on  a  page  Is  scored  here* 

(v)  Last  Record  Pointer:  Records  within  a  page  should  always  start 
at  a  1/2-word  boundary.  The  last  ten  bits  of  this  pointer  point  to  Che 
record  last  processed  in  the  page.  Hie  first  two  bits  of  the  pointer 
specify  the  type  of  processing  done,  tihich  could  be  one  of  Che  following 
three:  Read,  Write,  or  Edit. 

(vi)  Free  Word  Pointer:  This  points  to  the  first  free  1/2  word  in 
the  page,  beginning  at  a  1/2-word  boundary.  The  available  space  on  a  page 
is  documented  within  Che  page  as  a  list.  The  first  free  1/2  word  pointed 

to  by  this  pointer  would  specify  the  count  of  available  free  bytes  beginning 
at  the  1/2-word  boundary,  and  in  addition  would  contain  a  pointer  to  the 
next  free  1/2  word  in  the  page  starting  at  another  1/2-word  boundary.  This 
process  is  iterated  until  all  the  available  space  in  the  page  is  exhausted. 

(vii) ,  (viii) ,  (ix)  and  (x)  Counts  of  Page  Usage;  The  various  counts 
of  Che  way  the  page  was  used  would  determine  its  priority  nuiiR>er.  The 
priority  number  so  produced  may  be  used  for  page  allocation  in  a  memory 
hierarchy. 

(xi)  Directory  Type:  In  the  case  of  a  directory  page  the  type  of 
directory  is  identified  by  this  field.  The  directory  format  depends  on 
its  type. 

(xii)  Edit  Pointer:  This  was  referred  to  earlier  in  item  (il)b.  If 
a  user  wants  Co  edit  a  page  without  destroying  its  existing  contents 

the  page  may  be  tagged  as  OLD  and  the  editing  coBnands  for  the  page  may 
be  scored  in  one  of  its  slave  pages.  The  edit  pointer  field  would  Chen 
have  a  pointer  to  the  edit  commands  so  specified.  Every  time  the  page 
is  called  one  may  then  call  for  either  its  OLD  or  its  NEW  version. 

(xill)  Page  Group  Definition;  Each  page  may  have  a  group  of  slave 
pages  associated  with  it.  A  data  page  may  have  up  to  15  slave  pages,  and 
a  directory  page,  up  to  31  slave  pages.  The  data  within  a  master  page 
nav  contain  pointers  to  Che  records  in  any  one  of  its  slave  pages.  The 
pointer  format  is: 

51  II  I  BITS 

Slave  page  #  Displacement  in 
slave  page 

For  1  £  i  <  31  (or  15)  the  Virtual  Page  §  of  the  i*’*'  slave  page  would  be 
at  the  i^h  half-word  boundary  of  the  Page  Group  Definition  field  of  the 
header.  This  group  structure  of  pages  enables  one  to  economize  on  memory 
at  the  expense  of  a  slight  Increase  in  computation,  in  a  situation  where 
cross-referencing  among  pages  is  confined  to  page  groups.  It  should  be 
noted  Chat  every  page  in  the  file  would  be  the  master  page  of  its  associated 
group  of  up  to  15  (oT  31)  slave  pages.  Thus,  the  master  page  of  one  group 
would  itself  be  a  slave  page  of  another  group  and  vice-versa. 
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Each  variable  length  record  in  a  page  would  have  a  4>byte  record 
header,  with  the  following  format: 


5 


Record  flag 


16 


Pointer  to 
record  con¬ 
tinuation 
if  any 


11 


length- 1  of 
record 


A  record  may  be  either  complete  or  ineomplete .  and  it  may  or  may  not  have  a 
continuation  elsewhere  within  its  page  group.  The  first  two  bits  of  the 
record  flag  Indicate  these  attributes.  A  record  is  considered  to  be  complete 
if  it  is  a  well-defined  statement  in  CDLl.  Records  may  be  left  incomplete 
at  one  time  and  be  completed  at  a  later  date.  Complete  records  within  a  page 
need  not  appear  in  one  continuous  set  of  successive  bytes.  Whether  a  record 
la  complete  or  not,  it  may  appear  in  several  segments  within  a  page  group. 
These  record  segments  would  be  linked  together  as  a  list  via  the  record  con¬ 
tinuation  pointer  in  the  record  header.  Thus,  each  segment  of  such  a  record 
would  have  its  own  header,  and  would  itself  have  the  status  of  a  record  with¬ 
in  the  page.  The  last  segment  in  such  a  list  of  segments  would  point  to  the 
first  segment  of  the  record.  The  length  field  of  the  record  header  would 
always  contain  only  the  length  of  the  segment  associated  with  the  header. 

When  a  page  is  full,  it  is  said  to  be  dirty  if  one  or  more  of  the  records 
in  the  page  remain  segmented.  In  such  a  case  the  page  is  due  for  garbage  col¬ 
lection  (or  clean  up).  A  clean  page  would  not  thus  contain  segmented  records. 

(B)  Directory  Structure 

The  directory  for  searching  the  ODB  is  organized  around  a  central  hashing 
scheme.  This  hashing  scheme  and  its  associated  tables  are  used  to  translate 
a  given  key  (which  could  be  a  name,  label .  or  some  values  of  qualitative 
attributes  associated  with  the  objects  in  DDB)  to  its  corresponding  address. 
This  address  would  be  a  pointer  to  the  relevant  items  within  the  DDB  denoted 
by  the  key.  The  items  denoted  by  a  key  either  could  be  some  descriptive 
passages  within  the  DDB  or  could  themselves  be  some  entries  in  another 
directory  of  DDB  leading  to  further  search  within  the  DDB.  All  searches 
within  the  DDB  would  necessarily  begin  with  the  hashing  scheme.  Let  me, 
therefore,  first  describe  this  scheme. 


B-1.  The  Hashing  Scheise 

A  schematic  diagram  of  the  address  translation  process  through  hashing 
is  sham  in  Figure  5,  which  may  be  interpreted  as  follows: 

Explanation  of  Figure  5 

The  hash  search  scheme  makes  use  of  three  components: 

i)  Hash  Reference  Table  (BRT) 

11)  Variable  Length  Items  Bin  (VLIB) 
ill)  The  Hashing  and  Comparison  Routines 
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Figure  5.  A  Schepiattc  Diagram  of  the  Hash  Search  Scheme 


The  eearch  scheme  is  the  follovlng:  a  given  key  (the  input  key)  is 
hashed  both  by  H4SHER  1  and  HkSBBR  2  shown  in  Figure  5.  The  first  hMher 
comes  up  with  a  1  byte  number  <  225,  and  the  second  one,  with  a  nus^r 
<303,  which  is  a  prime  number.  The  mitput  of  tlm  first  hasher  points  to 
one  of  the  256  IfilT  pages  (as  Indicated  by  airow  ^  in  Figure  5),  which  is 
then  brought  into  core  (as  shown  by  arrows  ^  in  Figure  5).  Each  entry  in 
a  BRT  page  is  a  4-byte  item,  with  the  following  format: 


HRT  Entry  Format:  (4  bytes) 


(Length-1) 
of  the  KEY 


Ist  character  of 
the  key 


Relative  address  pointing  to  the 
corresponding  VLIB  entry 


Each  VLIB  entry  would  have  the  format  shown  below: 


VLIB  Entry  Format: 

(Length- 1)  of  key 


4 

4 

KEY  { 

□ 

Free  bytes  for  \Polnter  to  the  directory  entry 

flags  and  future  use  for  the  item  denoted  by  the  key 

Assuming  an  average  length  of  24  bytes  per  VLIB  entry,  one  would,  on  the 
average,  need  about  (503  x  24)/20483  6  VLIB  pages  for  each  ffilT  page.  The  503 
entries  in  a  HRT  page  would  occupy  503  x  4  =  2012  bytes,  leaving  a  remainder 
of  36  free  bytes  per  HRT  page.  These  36  free  bytes  are  used  to  store  the 
VF#'s  of  up  to  15  slave  pages  associated  with  the  HRT  page,  and  part  of 
other  page  header  entries.  The  slave  pages  of  a  BRT  page  would  be  either 
the  VLIB  pages  or  continuation  pages  for  the  HRT  page.  These  continuation 
pages  are  used  to  take  care  of  IBT  page  overflow.* 

The  output  of  the  second  hasher  would  point  to  a  full-word  boundary 
within  the  BIT  page  Just  brought  into  core,  as  shown  by  the  arrow  ^  in 
Figure  5.  The  HRT  entry  at  this  full-word  boundary  is  Che  item  of  Interest 
Co  us.  Let  us  call  it  HRIE.  The  length  and  first  character  of  key  in  the 
HRIE  are  compared  with  the  length  and  first  character  of  the  input  key.  If 
they  do  not  match,  then  the  input  key  is  rehashed  by  Che  HRSBER  2  and  the 
new  hash  address  so  obtained  is  again  used  similarly.  This  kind  of  probing 
of  Che  HRT  page  is  Iterated  until  a  successful  match  is  obtained.  This 
secondary  probing  is  indicated  in  Figure  5  by  the  broken  arrow  coming  out  of 
arrw  ^  .  Let  us  call  this  process  the  initial  matchina  process.  If  after 
251  such  probings  no  successful  initial  match  is  obtained,  then  the  input 
key  is  Interpreted  as  a  new  key  not  yet  entered  in  Che  hash  tables. 

When  a  successful  initial  match  does  occur,  Che  two-byte  pointer  in 
Che  HRTE  with  the  successful  match  is  used  to  bring  out  of  VLIB  Che 
appropriate  VLIB  page,  as  indicated  by  Che  arrows  ^  and  ^  in  Figure  5. 


*The  overflow  handling  technique  is  not  discussed  in  this  report. 
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The  full  key  In  che  appropriate  VLIB  entry.  In  the  VLIB  page  Just  brought 
Into  core,  ia  now  compared  with  the  Input  key,  Notice  that  by  this  time 
we  are  sure  that  the  length  of  the  input  key  and  Its  first  character 
agree  with  the  length  and  first  character  of  the  key  In  the  VLIB  entry. 
Therefore,  the  chances  of  now  obtaining  a  full  match  are  quite  good.  Let 
us  call  this  the  secondary  matchlna  process.  If  the  secondary  match  Is 
not  successful  then  the  Input  key  Is  also  rehashed  by  HASHER  2  and  the 
entire  process  Is  repeated.  The  secondary  matching  process  Is  Iterated 
until  a  successful  Initial  and  secondary  match  Is  obtained.  Here  also,  If 
after  251  such  probings  no  match  occurs  then  the  Input  key  Is  Interpreted 
as  being  new. 

Because  of  the  way  the  HRT  and  VLIB  tables  are  built  up  one  can  be 
reasonably  sure  that  all  secondary  match  attenpts  would  be  confined  to 
the  same  VLIB  page  Initially  brought  Into  core. 

Once  a  successful  secondary  match  Is  obtained,  the  4-byte  pointer  In 
the  VLIB  entry  with  the  successful  match  Is  chosen  as  the  DDB  address  for 
further  search  and  retrleyal  of  the  objects  denoted  by  the  key. 

The  HRT  as  presently  configured  can  accomnodate  address  translation 
for  up  to  503  X  256  -  128768  keys.  For  each  one  of  these  keys  the  address 
of  its  VLIB  entry  Is  called  the  Hash  Reference  Code  (HRC)  for  the  key. 

This  HRC  Is  a  3-byte  Item  with  the  following  format: 

HRC  FORMAT: 

AA  I 

Free  bits.  \Relatlye  Page  # 

May  be  used  \of  VLIB  within  the 
for  flags  collection  of  all 

VLIB  pages 

This  HRC  will  be  used  throughout  the  DDB  for  the  Identification  of  the 
key.  Thus,  the  HRC  of  a  key  may  never  be  changed. 

A  given  key  In  CDLl  may  denote  more  than  one  Item  In  the  DDB.  To 
Identify  an  Item  uniquely  in  the  DDB  It  Is  generally  necessary  to  have 
at  most  two  keys;  one  of  these  two  keys  would  be  the  name,  label,  or 
attribute  of  an  object,  and  the  other  key  would  be  the  name  or  label  of 
the  scope  of  the  object.  Thus,  a  key  In  CDLl  would  be  unique  only  within 
a  scope.  The  DDB  would  have  thousands  of  such  scopes.  Hence,  the  number 
of  objects  denoted  by  these  keys  could  be  many  times  greater  than  the 
total  number  of  keys. 

CDLl  has  two  kinds  of  scopes:  The  first  kind  of  scope  is  the  scope 
of  modules*,  which  are  identified  by  module  titles  (names) .  The  second 


*See  Ref.  1  for  a  discussion  of  modules  and  module  types. 


Dlsplaceieent  within 
the  page  to  the  VLIB 
entry. 
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kind  of  scope  Is  that  of  descriptive  end  Interpretive  blocks.  These  ere 
similar  to  the  BE6IN-END  blocks  In  AL60L>  and  are  identified  by  labels*, 
or  names  of  items  interpreted.  Both  these  scopes  may  have  a  hierarchical 
structure  of  subscopes.  Thus,  the  neae  or  label  used  to  identify  a  scope 
would  be  its  tree  name  within  this  hierarct^.  In  the  case  of  scopes  the 
VLIB  entry  for  the  key  identifying  the  scope  would  have  a  pointer  to  its 
corresponding  scope  directory.  The  scope  directory  would  be  used  to  locote 
all  the  objects  in  DOB  associated  with  the  scopes.  In  the  ease  of  module 
scopes,  the  module  type*  would  deteiisine  the  submodules  it  might  have  and 
the  directory  for  the  submodules. 

In  the  case  of  labels  the  scope  of  a  label  la  restricted  to  its  block 
or  module.  In  the  case  of  names  of  declared  items  the  scopes  of  such 
items  would  permeate  all  submodules  or  sub-blocks  of  the  block  or  module 
in  which  the  item  is  declared.  Alao,  in  certain  cases  the  scopes  of  names 

would  be  global,  i.e.,  throughout  tbe  entire  descriptive  file  the  name  would 

uniquely  denote  the  same  item.  The  scope  directory.  deelaratio.iS  directory. 
and  label  directory  are  organised  to  indicate  these  various  scope  inclusion 
properties. 

The  descriptive  items  associated  with  a  name  depend  upon  the  definition 

format*  of  the  kind  of  object  denoted  by  the  name.  It  should  be  possible  to 

locate  for  each  name  all  its  associated  definitions,  attributes,  values, 
functions,  interpretations,  alternate  definitions,  alternate  names,  restric¬ 
tions,  etc.  The  declarations  directory  would  contain  the  relevant  pointers 
to  accomplish  such  identifications. 


Let  me  now  briefly  describe  how  these  three  directories  are  organised. 
Together  with  the  hash  search  scheme  these  constitute  tbe  core  of  the  entire 
DDB  structure.  In  addition  to  these  directories,  there  are  several  others 
in  the  DDB,  such  as  user  directory,  name  usage  directory,  item  relationship 
directory,  retrieval  functions  directory,  definition  format  directory,  and 
declaration  format  directory,  etc.  I  shall  not  describe  these  in  detail  in 
this  report. 


B-2.  Tbe  Scope  Directory  (SD) 


Each  scope  in  DDB  has  s  unique  name,  and  is  identified  within  the  DDB 
by  a  unique  ?'byte  scope  number  having  the  foilwing  format: 

Scope  Humber  Format: 


BITS 


Page  #  within  / 
the  scope  directory 
pages. 


DisplacemMt  to  a  4-word 
boundary  within  the  directory 
page,  to  tbe  scope  directory 
entry. 


*Flease  see  Ref.  1. 


This  scope  nuober  is  used  In  ell  cross  references  within  the  DOB.  Each 
scope  directory  entry  is  a  48-byte  item  with  the  format  shown  in  Figure  6. 
The  various  fields  in  this  directory  entry  have  the  following  significance: 

1)  hRC:  This  is  the  Hash  Reference  Code  for  the  scope  name  or  label. 

11)  Alternate  Identifier;  Each  scope  In  DDB  could  have  alternates 
described  for  them.  These  alternates  might  eoatain  either  several  versions 
of  design  for  a  given  item  or  alternate  descriptions  of  a  like  design. 

Each  scope  may  have  up  to  15  alternates^  idiich  are  Identified  by  numbers 
1  through  15,  and  up  to  16  which  are  Identified  by  alternate  names.  Such 
eltemate  scopes  would  be  denoted  by  the  naming  scheme: 

"Label  or  Name  of  Scope  ///ALT(#  or  name)". 

ill)  Scope  Type;  If  the  scope  is  a  module  then  the  scope  type  would 
be  the  same  as  the  module  type.  Otherwise,  the  scope  type  would  be  one  of 
the  following: 

Operation  Interpretation  Block, 

Macro  Definition  Block 
Function  Interpretation  Block, 

Formal  Definition  Block, 

Declaration  Block,  or 
Begin- End  Block. 

iv)  Scone  Flag;  The  flag  would  indicate  the  information  shown  In 
Table  II  by  virtue  of  its  bit  values.  Several  bits  in  the  flag  have  been 
left  undefined  for  future  use. 

The  remaining  fields  point  to  the  various  directory  entries  associated 
with  the  scope.  The  pointers  to  parent/sibling  and  descendant  scopes,  in 
effect,  specify  the  hierarchical  structure  of  the  scopes. 

TABLE  11 
SCOPE  FLAG 


Bit 

Bit  Values 

# 

0 

1 

0 

Ho  Alternates 

Has  Alternates 

1 

No  Restrictions 

Has  Restrictions 

2 

No  User  Restrictions 

Res  User  Restrictions 

3 

Has  No  Errors 

Errors  Exist 

4 

Meeds  Editing 

Mo  Editing 

5 

No  Functions  on  Scope 

Functions  on  Scope 

6-15 

NOT 

USED 

A  module  scope  could  have  two  kinds  of  descendent  scopes,  a  descendant 
sub-module  or  a  descendent  block.  A  block  scope  cannot  have  as  Its  descendent 
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le  Director/  Entry  Format 


a  module;  it  could,  hovever,  have  other  blocks  as  its  deacendents.  The 
deacendent  blocks  of  a  module  are  separately  Identified,  with  special 
pointers,  In  the  scope  directory. 

B-3.  Label  Directory  (LD) 

Labels  are  used  in  DDB  to  Identify  records  (CDLl  statements),  and 
blocks  within  a  file.  A  record  or  a  block  in  DDB  is  uniquely  identified 
by  its  label  and  the  name  of  the  scope  in  which  it  occurs.  Labels  in  DDB 
could  themselves  have  a  tree  structure,  as  is  evidenced  by  its  directory 
entry,  shown  in  Figure  8.  To  get  at  a  record  or  a  block  in  DDB  it  is 
necessary  to  use  two  Keys;  its  scope  name  and  Its  label .  The  schematic 
search  path  for  this  is  shewn  in  Figure  7. 

The  VLIB  (Variable  Length  Items  Bin)  entry  for  the  scope  name  would 
contain  a  pointer  to  the  scope  directory  entry  for  the  scope.  This  scope 
directory  entry  itself  would  contain  a  pointer  to  the  Label  Directory  (LD) 
page  associated  with  the  scope.  The  VLIB  entry  for  the  label  would  point 
to  the  head  of  a  list  within  this  LD  page.  This  list  in  t\urn  would  contain 
the  label  directory  entry  for  the  label  in  search.  By  searching  this  list 
the  directory  entry  for  the  label  might  be  identified. 

Notice  that  a  same  label  might  appear  in  DDB  in  several  different  scopes, 
each  one  of  which  would  have  its  own  associated  label  directory  page. 


page  for  the  scope 


Figure  7 .  Schematic  Diagram  of  Record  or  Block  Search  in  DDB 


To  reatrlcclons 


Entry  Ponaata  for  the  Label  Dtree^n1 


In  all  these  LD  pages  a  search  for  a  label  would  begin  at  the  head  of 
a  list  pointed  to  by  the  VLIB  entry  for  the  label.  The  relative  address 
of  this  head  of  the  list  within  the  LD  page  would  be  the  same,  for  a  given 
label.  In  all  these  various  LD  pages.  This  head  address  Is  obtained  by 
hashing  the  label. 

A  label  directory  entry  for  a  new  label  in  a  scope  Is  made  as  follows: 
First,  the  LD  page  for  the  scope  Is  Identified  from  the  scope  name;  then 
from  the  existing  VLIB  entry  of  the  label  (If  none  exists  then  a  VLIB 
entry  is  created),  the  pointer  to  the  head  of  the  list  associated  with  the 
label  Is  obtained.  If  the  location  of  this  head  Is  empty  In  the  particular 
LD  page,  then  the  LD  entry  for  the  label  Is  made  xight  at  the  head  of  the 
list.  Otherwise,  the  LD  entry  Is  suffixed  to  the  tall  of  the  list  already 
present . 

The  label  directory  entry  formats  are  shown  In  Figure  8.  The  entries 
are  all  16  bytes  long.  There  are  four  different  kinds: 

a)  Record  Pointer 

b)  Scope  Begin  Entry 

c)  Scope  End  Entry 

d)  Alternate  Record  Entry 

The  various  fields  In  the  formats  have  the  significance  shown  In  Figure  8. 
All  cross-referencing  addresses  within  the  LD  have  the  following  format: 


Relative  address  to  a 
‘quadruple  word  boundary 
In  page. 


Each  LD  page  may  contain  labels  for  up  to  four  different  module  scopes. 
These  modules  are  assigned  local  nuid>ers  0,1,2,  and  3  within  an  LD  page; 
the  local  numbers  are  part  of  the  entry  flag  for  each  LD  entry,  as  shown 
In  part  a)  of  Figure  8. 

B-4.  Declarations  Directory  (DP) 

This  Is  used  to  refer  to  objects  declared  within  descriptions  in 
different  scopes.  An  object  In  the  description  Is  Identified  uniquely 
by  Its  name  and  the  scope  of  the  name.  The  directory  entry  for  a  name 
In  the  Declarations  Directory  (DD)  la  accessed  very  much  In  the  same 
way  as  a  Label  Directory  (LD)  entry.  From  a  given  name  of  an  object  It 
Is  necessary.  In  general,  to  access  the  following  associated  Information: 


BITS: 
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Relative  page  # 
within  a  page  group 
of  32  pages. 
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1.  Name  Scopes:  Scopes  In  %rhlch  the  same  name  has  been  declared. 

2.  Name  Usage:  Scopes  in  which  each  token  declaration  of  the  name 
has  been  used. 

3.  Definitions;  The  definitions  associated  with  the  name.  These 
would  depend  on  the  kind  of  name  being  defined. 

4.  Initial  Value:  Sometimes  nameR  might  be  assigned  initial  values. 

5.  Current  Value:  The  current  value  of  the  name. 

6.  Attribute  Values;  Values  of  attributes  associated  with  the  name. 

7.  Aliases;  Names  which  are  aliases  to  the  name. 

8.  Author  of  the  name. 

9.  Functions  on  name. 

10.  Conditions  on  the  declaration  of  a  name. 

11.  Restrictions  on  a  name. 

Each  item  In  a  Declarations  Directory  (DD)  page  Is  a  list.  Just  like 
the  lists  In  an  LD  page.  The  pointer  In  the  VLIB  entry  of  a  name  would  point 
to  the  head  of  the  list  In  DD.  The  search  for  a  DD  entry  for  a  given  name 
would  be  exactly  as  the  search  for  a  LD  entry  of  a  label,  discussed  In 
the  previous  section.  An  object  In  DDB  would  be  uniquely  identified  by  Its 
name  and  the  scope  of  the  name. 

The  VLIB  entry  for  a  name  would  contain  an  additional  pointer,  which 
would  point  to  a  list  containing  all  the  scopes  In  which  the  name  had 
been  declared. 

The  DD  entries  fall  Into  two  classes:  One  for  names  and  another  for 
aliases  (alternate  names)  given  to  an  initially  declared  name.  The  formats 
for  these  two  entries  are  shown  In  Figures  9(a)  and  (b).  All  cross-referencing 
within  DD  pages  would  have  the  same  address  format  as  those  used  In  LD 
pages.  Also,  as  In  the  case  of  LD,  each  DD  page  may  contain  declarations  for 
up  to  four  different  scopes.  These  scopes  are  Identified  locally  within  a 
DD  page  by  their  local  scope  numbers. 

The  Scope  Directory  (SD),  Label  Directory  (LD)  and  the  Declarations 
Directory  (DD)  are  the  three  principal  directories  used  In  DDB.  Besides 
these  there  are  several  other  directories  to  which  entries  In  SD,  LD,  and 
DD  point.  I  have  not  discussed  the  details  of  these  other  directories  In 
this  report.  The  hash  search  scheme,  and  the  structure  of  SD,  LD,  and 
DD,  provided  the  basic  foundations  on  which  DDB  would  be  built. 
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To  definition 
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Declarations  Directory  Entry  For  a  Declaration 
Without  Symbolic  Equality  (A  Name  and  Not  an  AHa« 
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In  previous  reports ^  CDLl  --a  computer  description  language  —  has 
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of  programs,  on  the  RCA  Spectra  70  computers,  to  generate  appropriate  file  struc¬ 
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of  design-aid  systems  can  be  based  upon  them,  saving  a  duplication  of  effort, 
guaranteeing  an  Integrated  overall  system,  and  avoiding  built-in  obsolescence. 

The  final  state  of  the  work  done  under  this  cmttract  is  given,  with  details 
of  the  file  and  directory  structures  which  have  been  Implemented. 
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